Blogs

Technology governance is a funny thing.  Its goal is rigidity, with just the right dash of flexibility.  Its goal is also to provide just enough information at the right time.  Storing content with appropriate meta-data is a big part of this.  However, meta-data tends to make planning tricky, or fun, depending on how you look at it.  When it comes to planning for what meta-data to include/extract from an inputted document, to me, it sometimes feels like when my mom gave me a whole store to pick a $15 toy for myself, simply impossible to decide.

Pick too much meta-data and you just confuse the users when retrieving content, or when uploading.  You potentially increase the time it takes to enter a document, thus the cost.  But, include too little meta-data in a period of days, months, years you could find yourself in a serious problem. Everything will run until that one day when you realize you really needed that pesky number that appears on all documents, but you did not know what it was for.  Retroactively applying meta-data is often takes longer and cost more than the initial input.  It also could introduce variables such as kludged custom code to get the job done.

So what is the discerning information architect to do?  After all, the thing I preach more than anything is planning ahead as much as you possibly can.  What I find is that categorizing requirements tends to unravel the mystery.  Categorization includes the functional requirement description, the priority, the expectations, and the time/cost effort, at a minimum.

I recommend segmenting your meta-data requirements into buckets:  “Critical”, “nice to have”, and “exceptional” for example.  “Critical” is the meta-data that is absolutely necessary to a business process, “nice to have” is the meta-data that will dramatically improve findability and ability to execute on business processes, and “exceptional” is the meta-data above and beyond anything needed for today’s operation.  Theoretically, you could extract all meta-data from a document which would be exceptional from a capture standpoint, but not from a user standpoint because there is too much information.  So there is always this push and pull you have to be aware of. 

While implementing, deciding how deep to take your meta-data requirements is tricky.  What I tend to consider is two primary points. First, is the effort to get to the exceptional bucket worth it today or in the foreseeable future?  Often organizations find that with just a few little tweaks, they can extract the additional meta-data, while others find that one field on a document could take them months of additional implementation time and regression testing.  Second, is it possible to hide meta-data that you don’t need in your system?  For example, can you create views for your users which give them just the right information at the right time?  With this trick, you can favor the extraction of more meta-data and hide everything that is not in the “critical” or “nice to have buckets”.

As you plan you should also consider the process required to add new meta-data to existing documents retroactively, and new documents.  If you decide in the future you do need more meta-data, what is the impact of adding it?  In the world of document imaging this would include a process of re-OCRing or re-imaging a document.  Being prepared may just be the key to setting up your environment to both satisfy current requirements and prepare for the unforeseen future.

Yes governance and meta-data are as much an art as they are a science.  They are a constant dance between not too much, but not too little.  However, don’t be afraid to be creative and explorer ways to have both worlds, because in this case, it just might be possible.